OLTP vs. OLAP

如上節所述，處理交易過程細節繁多，且一個企業中可能就有數十種不同的交易處理系統，如：

• 產品銷貨系統
• 供應商管理系統
• 客服網站系統
• 庫存系統
• 人資管理系統

等視各產業及功能的不同，用來管理各種線上交易(online transaction processing, OLTP)的系統，各系統間彼此功能迥異而複雜，因此各系統通常為獨立且有專門團隊來運行，以確保日常業務交易可被正常處理。

而何謂資料分析需求呢？其特性又為何？

當企業收集了大量的業務資料，管理者自然會希望能從自家資料 (data) 中去蕪存菁，得到對決策有幫助的資訊 (information)，如以下：

• 各分店的營收？成本？各地區間是否有差異？
• 促銷活動成效如何？使各分店營收成長多少百分點？
• A產品與哪些產品最常被一同購買？

等各類對運營狀況的查詢，這類使用資料庫的模式則被稱為線上分析處理 (online analytic processing, OLAP)，DDIA 對兩者差異的描述如下：

可以看到兩類系統的讀寫模式迥異：

• 交易系統通常對資料庫不會一次有大量紀錄的查詢 (例如 查詢小明的帳戶餘額，僅需以小明的帳戶號碼當key，取得小明一人之帳戶資料即可)。
• 分析系統不同，若需得知公司整體運營狀況，通常需對整家公司 (或特定分店整體資料) 做聚合運算 (如加總、計算平均)。

這樣需對資料庫掃描 大量紀錄 的操作，會對資料庫效能會有顯著影響，一般不太可能犧牲交易系統之效能給急迫性相對低的分析需求使用 (畢竟分析報告不做不會怎樣，日常交易弄不好可是會引起客訴的)。

資料倉儲

為了解決分析人員沒做完報表還是會被老闆罵的問題，資料倉儲(Data warehouse) 應運而生：

• 資料倉儲的概念是一個 獨立的 資料庫，分析人員可以查詢他們想要的內容而不影響 OLTP 操作。
• 資料倉儲包含公司各種 OLTP 系統中所有的 read-only 資料副本。
• 從 OLTP 資料庫中提取資料 (batch or real-time)，轉換成適合分析的模式，清理並加載到資料倉儲中。

前點所述將資料存入倉庫的過程稱為 ETL (Extract, Transform, Load)，如下圖 :

明日預告

系列文明日《資料倉儲的不足？》將接續本日內容，闡述資料倉儲雖好，但也不是萬能，那麼到底有哪些可以被改進的不足之處呢？

Know me more

My Linkedin: https://www.linkedin.com/in/benny0624/
My Medium: https://hndsmhsu.medium.com/